What is PCI SSF/PCI Secure SLC/PCI S3?

This new article presents a brief introduction to the Software Security Framework or PCI SSF (Payment Card Industry Software Security Framework), which replaced to standard PA-DSS (Payment Applications Data Security Standard) in October 2022.

What is it?

All articles in the series «What is it?‘:

Introduction

One of the easiest targets to attack by a cybercriminal is a payment application that is outdated, does not use strong cryptography for the protection of sensitive data, or is incorrectly configured and/or uses default values. In order to define basic parameters for card data protection in commercial payment applications and facilitate their integration in environments subject to compliance with the standard PCI DSS (Payment Card Industry Data Security Standard), in 2004 VISA developed the basis for what would later become the standard PA-DSS (Payment Applications Data Security Standard) which was completely replaced by the new framework PCI SSF (Payment Card Industry Software Security Framework) in October 2022.

Origin

In 2005 VISA USA published the document Payment Application Best Practices (PABP) as a complementary part of your program Cardholder Information Security Program (CISP). This document contained eleven security principles to be applicable both in the software development process and during the deployment, operation and maintenance of commercial payment applications (sold, distributed or licensed by third parties) involved in authorization or settlement processes in credit and debit card transactions and used by merchants or service providers.

The use of these best practices was completely voluntary (no mandatory application or sanctions were defined if not used) although it allowed interested companies to certify their software through a Qualified Security Advisor (QSA) to be listed on the VISA website.

The VISA PABP document laid the groundwork for security controls in payment applications to be taken into account on two main fronts:

For internally developed applications, within the PCI DSS standard under requirement 6 «Develop and maintain secure systems and applications‘, and
For commercial payment applications, within standard PA-DSS (Payment Applications Data Security Standard).

On 15 April 2008, the PCI Security Standards Council (PCI SSC) published the standard PA-DSS (Payment Applications Data Security Standard) as an evolution of VISA PABP, formalizing the use of security controls in the development of software for commercial payment applications and defining the criteria for its use as a complementary element of security in environments affected by PCI DSS compliance.

Eleven years later, in January 2019, the PCI SSC publishes a new framework for payment application security: PCI SSF (Payment Card Industry Software Security Framework), incorporating new requirements aligned with the development of modern payment applications. This framework completely replaced the PA-DSS standard in October 2022.

What is (or was) PA-DSS (Payment Applications Data Security Standard)?

The standard PA-DSS (Data security standard for payment applications – Payment Applications Data Security Standard) was first published in 2008 and its final version was the 3.2, which was published in May 2016. This standard was replaced by PCI SSF in October 2022.

PA-DSS had fourteen requirements, ranging from card data protection in storage and transmission, to security management in the software development lifecycle and secure deployment in the customer environment:

Requirement 1: Do not retain full track content, card verification code or value (CAV2, CID, CVC2, CVV2) or PIN block data
Requirement 2: Protect the cardholder's stored data
Requirement 3: Provide secure authentication features
Requirement 4: Record the activity of the payment application
Requirement 5: Develop secure payment apps
Requirement 6: Protect wireless transmissions
Requirement 7: Evaluate paid apps to fix vulnerabilities and to maintain app updates
Requirement 8: Facilitate the implementation of a secure network
Requirement 9: Cardholder data should never be stored on a server connected to the Internet
Requirement 10: Provide secure remote access to the paid app
Requirement 11: Encrypt sensitive traffic from public networks
Requirement 12: Encrypt non-console administrative access
Requirement 13: Maintain a PA-DSS Implementation Guide for Customers, Resellers, and Integrators
Requirement 14: Assign PA-DSS responsibilities to staff and establish training programs for staff, customers, resellers and integrators

One of the main objectives of PA-DSS was to optimize the security levels of commercial payment applications when integrated into a PCI DSS compliant environment, minimizing the possibility of security failures that would allow the commitment of the PAN (main account number), the complete content of the track, the codes and verification values of the card (CAV2, CID, CVC2, CVV2), the PIN data and the PIN block, as well as fraud resulting from security failures in the application.

Payment applications eligible to be analyzed under the PA-DSS standard and listed on the PCI SSC website must meet the following criteria:

Store, process or transmit cardholder data as part of authorisation or settlement processes; and
To be sold, distributed or licensed by third parties

In November 2022, the PCI SSC announced in its official blog the final withdrawal of PA-DSS and its replacement by PCI SSF. From that time all documents related to this standard (support documents, report templates, FAQs and the standard as such) were removed from the PCI SSC document library.

What is PCI SSF (Payment Card Industry Software Security Framework)?

Due to current changes in terms of development methodologies, technologies, application types and their related vulnerabilities, the PA-DSS standard It was starting to get old-fashioned.. In response, the PCI SSC began to develop a new approach to developing secure payment applications with modern needs, updating, optimizing and extending the PA-DSS criteria throughout the secure development lifecycle (Secure Software Development Lifecycle – SSDLC). This new framework was named after PCI Software Security Framework and was published for the first time in January 2019.

The software security framework (PCI Software Security Framework) is a set of software security standards, including its validation programmes and the listing of certified applications. Currently, there are two standards in this framework:

PCI Secure Software Standard – PCI S3 (current version: 2.0 – published in January 2026)
Secure Software Lifecycle (Secure SLC) Standard (current version: 1.1 – published in February 2021)

The formal assessment of compliance with the standards that make up this framework is carried out by approved companies called Secure SLC Assessor Companies and its employees (Secure SLC Assessors).

What is PCI S3 (Secure Software Standard)?

The Secure Software Standard (PCI Secure Software Standard) o PCI S3 defines a set of security requirements and associated assessment procedures that help ensure that payment applications adequately protect the integrity and confidentiality of both payment transactions and their related data. Its current version is the 2.0, published in January 2026.

PCI S3 includes a set of basic requirements (core) which apply to all types of paid software, regardless of the functionality of the software or the underlying technology. These basic requirements (core) twelve (12) safety objectives are organised (Security Objectives) and four (4) additional modules, as listed below:

Core – All Software

Software Architecture, Composition, and Versioning
Sensitive Asset Identification
Sensitive Asset Storage and Retention
Sensitive Modes of Operation
Sensitive Asset Protection Mechanisms
Sensitive Asset Output
Random Numbers
Key Management
Cryptography
Threats and Vulnerabilities
Secure Deployment and Management

Modules

Module A – Account-Data Protection: Additional security requirements for software that stores, processes and/or transmits account data (as defined in PCI DSS).
Module B – POI Device Software: Additional security requirements for software intended to be deployed and executed on Point of Interaction devices (Point-of-Interaction – POI) which have been evaluated and approved in accordance with the PCI PTS POI standard and programme.
Module C – Publicly-accessible Software: Additional security requirements for software that contains, even partially, an interface that is accessible through public networks.
Module D – Software Development Kits: Additional security requirements for software that is part of a software development kit (SDK).

In the future, additional modules will be added to this standard to address other types of software, use cases or technologies.

This standard applies to paid software that is sold, distributed or licensed by third parties. This includes payment software intended to be installed on customer systems, as well as payment software deployed to customers "as a service" (As-a-Service) via the Internet. At the time of publication of this standard, the following criteria must be met in order for an application to be evaluated under these requirements:

Participate in, support or facilitate payment transactions directly, y
Store, process or transmit card data in clear text and can therefore be validated by both the Secure Software Standard (PCI S3) and Module A – Payment Card Data Protection, y
Be a product available on the market developed by the software vendor for sale to multiple organizations.

Validation of the PCI S3 standard is not intended to:

Software developed in-house for the exclusive use of the company that developed it
Software developed and sold to a single customer for the exclusive use of this
Payment software operating on any customer's mobile electronic device that is not solely dedicated to accepting payments for transaction processing
Software products that are operating systems, databases or platforms, whether these can store, process or transmit card data.
Payment software intended to be used in hardware terminals.

Future modules are planned to support some of these use cases. Software that is not eligible for validation at initial program launch will not necessarily remain ineligible for the entire life of the program. All exclusions will be re-evaluated each time a new module is added to the Secure Software Standard (PCI S3) and as the program evolves.

Application validations with the Secure Software Standard (PCI S3) have an expiration of three years.

Finally, it is important to highlight that the fact that an entity has to use software validated according to the Secure Software Standard (PCI S3) is determined by the directives of the payment brands and not by the PCI SSC.

What is PCI Secure Software Lifecycle (Secure SLC) Standard?

The Secure Software Life Cycle Standard (PCI Secure Software Lifecycle (Secure SLC) Standard) defines a set of security requirements and associated test procedures for software vendors to validate how they properly manage payment software security throughout the software lifecycle. Validation, according to the Standard, demonstrates that the software vendor has mature secure software lifecycle management practices to ensure that their payment software is designed and developed to protect payment transactions and data, minimize vulnerabilities, and defend against attacks. Its current version is the 1.1, published in February 2021.

The PCI Secure SLC standard is intended for vendors/software providers who develop software for the payment industry. Software vendors who have their software lifecycle management practices validated will be recognized in the List of Qualified SLC Providers PCI SSC Insurance.

Like the PCI S3 standard, the PCI Secure SLC standard is organized into four (4) security objectives that include ten (10) control objectives:

Software security governance (Security Governance Software)
- Responsibility and safety resources (Security Responsibility and Resources)
- Software Security Policy and Strategy (Software Security Policy and Strategy)
Secure Software Engineering (Secure Software Engineering)
- Threat identification and mitigation (Threat Identification and Mitigation)
- Detection and mitigation of vulnerabilities (Vulnerability Detection and Mitigation)
Secure software and data management (Secure Software and Data Management)
- Change management (Change Management)
- Protection of software integrity (Integrity Protection Software)
- Protection of sensitive data (Sensitive Data Protection)
Secure communication (Security Communications)
- Supplier Safety Guide (Vendor Security Guidance)
- Communications with stakeholders (Stakeholder Communications)
- Software Update Information (Software Update Information)

What is the relationship between the PCI S3 standard and the PCI Secure SLC standard?

The PCI S3 standard and the PCI Secure SLC standard are two separate and independent standards. While both standards address some of the same concepts, each of them realizes them from a different perspective:

The secure functionality and security features of an application are covered in the PCI S3 standard
Secure software development processes are covered in the PCI Secure SLC standard

That said, additional flexibility is provided to PCI Secure SLC Qualified Providers as part of validating their payment software to the PCI S3 standard. These providers will be empowered to conduct and self-manage their own software delta assessments (as part of validating their payment software products to the PCI S3 standard) with reduced involvement or supervision by the qualified advisor.

How will the migration from PA-DSS to PCI SSF take place?

The PCI Software Security Framework has an immediate impact on applications currently validated under the PA-DSS program. Upon expiration, all payment applications validated under PA-DSS will be moved to the list of "Acceptable only for pre-existing deployments" (Acceptable Only for Pre-Existing Deployments).

More information in the document Transitioning from PA-DSS to the PCI Software Security Framework.

Relationship between PCI DSS and Software Security Framework standards (PCI S3 and PCI Secure SLC)

In the PCI DSS version 4.0 a specific section was included in the standard document (Appendix F – Leveraging the PCI Software Security Framework to Support Requirement 6) which describes in detail how software validated under the controls of the PCI S3 and PCI Secure SLC standards can be used to meet the requirements of the standard or when using the custom approach (customized approach):

When using customized software that has been developed and maintained by an approved vendor such as Secure SLC Qualified Vendor, compliance with control 6.2 is facilitated and the custom approach is supported in controls 6.3 and 6.5. In this case, it must be validated that the supplier that develops the software is listed in the inventory of Secure SLC Qualified Vendors, that the software is developed and maintained as part of that vendor's software validation and that the entity that must comply with PCI DSS has followed the implementation guidelines.
When using customized software that has been developed according to the PCI Secure SLC standard. The entity that must comply with PCI DSS may also use PCI Secure SLC as a reference for its internal developments. To validate it, a Secure SLC advisor must review the development process and document it in related reports.
Cuando uses third party-provided software validated under PCI S3. In this case, the use of software validated under PCI S3 can support compliance with control 6.2.4 and implementation of the custom approach for controls 6.3 and 6.5. To do this, the QSA advisor must review the compliance reports for such software (Secure Software Report on Validation (ROV) and Secure Software Attestation of Validation (AOV)) and validate that these reports are not expired.

Other additional considerations

The standards that make up the Software Security Framework (PCI SSF) are completely independent of other PCI SSC standards. Using payment software certified under these standards can help support the security of cardholders' data environment (Cardholder Data Environment – CDE) of an entity, but does not cause an entity to comply with PCI DSS, nor does it imply compliance with or the result of validation of any other PCI SSC standard. Entities must ensure that all payment software is deployed in a PCI DSS compliant manner and is included in their annual assessment to verify that the software is properly configured and meets the applicable PCI DSS requirements.